As a modern enterprise grows in size and complexity, its underlying business processes also become increasingly complex. Moreover, today's highly dynamic business environment requires processes to adapt to constant change in order for a business to prosper. Process complexity is often hidden within enterprise applications as hard-coded procedures and is difficult to change. As a result, agility and awareness of the actual business processes in place is low, leading to inefficiencies and increased costs. Consequently, the current wave of process management, Business Process Management (BPM), has been gaining a lot of traction, promoting process centricity and promising business agility.
A typical BPM lifecycle as illustrated in FIG. 1, starts with Process Analysis, during which business analysts specify the processes currently in place (the “as-is” processes) and select processes for automation. Business analysts then model the desired processes (the “to-be” processes) based on their assessment of the as-is processes. During Process Automation, business and technical architects translate the models of the to-be processes into technical terms built into application code by an implementation team. Finally, during Process Monitoring, execution of the newly automated processes is monitored to measure selected key performance indicators and to ensure process compliance, efficiency or effectiveness.
Problems of the BPM Lifecycle
Process Discovery is an important part of Process Analysis in which the as-is processes are specified. It is a tedious, manual, and labor-intensive task involving interviews with stakeholders and subject matter experts, reviews of user manuals, existing application code and transaction logs. Due to confusing notions of what is and what is not a process and the lack of agreement between the stakeholders about how each process is or should be executed, Process Discovery may take as long as two months, potentially undermining the success of the entire BPM initiative.
Even after a very thorough process analysis, expecting the complex processes to be fully specified before proceeding with implementation is unrealistic. Many exception paths will remain unspecified at process design time leading to numerous process change requests that are hard to incorporate after process implementation has started. One exemplary BPM project investigated reported as many as 300 process change requests a week before the first release, likely an indication of serious problems during Process Analysis.
Process Monitoring can reveal useful insights into process efficiency, effectiveness and process compliance. However, it does not typically give the business analyst enough visibility into what happens when the automated process does not apply to a given situation. Examples include exceptional circumstances not covered by the automated process and handled manually by the worker in order to complete a transaction, or cases when business conditions have changed requiring a manual override of the outdated automated process. The manual activities followed by the workers in such cases are generally not catalogued, evaluated or reused. Moreover, in order to include them in a subsequent process automation cycle, manual process discovery is required to specify them all over again.